In order to better understand the background of the subject invention, explanation of some of the terminology utilized hereinafter will first be provided. A term well known in the art as a symmetric multiprocessor (SMP) refers to an aspect of hardware in a computing system and, more particularly, relates to the physical layout and design of the processor planar itself. Such multiple processor units have, as one characteristic, the sharing of global memory as well as equal access to I/O in such a typical SMP system.
Yet another such term which will be hereinafter used and commonly associated with modern complex computing systems is a "thread". The term thread in a general sense refers merely to a simple execution path through application software and the kernel of an operating system executing with the computer. As is also well understood in the art, it is commonplace for multiple such threads to be allowed per a single process image.
Yet another concept which will be utilized hereinafter in describing the invention is one of "locks" or "mutexes". It is typical in modern computing systems to have critical sections of code or shared data structures such as in shared libraries whose integrity is extremely important to the correct operation of the system. Such locks/mutexes are devices employed in software (and hardware) to "serialize" access to these critical sections of code and/or shared data structures.
Two types of locks are typically encountered in the art, namely blocking locks and simple or "spin" locks. Blocking locks are of the form which cause a thread requesting the lock to cease being executable, e.g. to go to "sleep" as the term is employed in the art, if the lock is currently held by another thread. Spin locks, in contrast, do not put waiting threads to "sleep", but rather, the waiting threads execute a spin loop, and thus repeatedly continue to request the lock until it is freed by the current thread "owner". Blocking locks are typically used for large critical sections of code or if the operating system kernel must differentiate between threads requiring data structure read-only capability and threads requiring the capability to modify the data structure(s). This latter read-write type lock may be found implemented, for example, in the current OSF/1 operating system release of the Open Software Foundation (OSF).
One other term utilized hereinafter is the concept of code being multithread-safe. Such code is considered to be thread/MP-safe if multiple execution threads contending for the same resource or routine are serialized such that data integrity is ensured for all such threads. One way of effecting this is by means of the aforementioned locks.
In modern uniprocessor, single process model systems employing shared libraries, routines in such shared libraries do not require any form of hereinbefore noted serialization with respect to other routines in the library or multiple callers of the same routine. There is thus no problem with respect to shared or global data structures requiring use of locks or mutexes to prevent conception.
Moreover, even as between processes in multiprocessor systems, data corruption problems are typically avoided where private/local copies are data are maintained by the respective processes.
As a specific example of the foregoing, in version 3.2 of the AIX(tm) operating system of the IBM Corporation, shared libraries shipped for execution on compatible machines have to only run in a single process model on a uniprocessor system. Accordingly, there is no need for utilizing locks or mutexes to serialize access to shared or global data structures. However, in contrast, with respect to subsequent releases of the aforesaid operating system such as that employing Distributed Computing Environment (DCE) functionality, the process model has been changed from a single process to multiple threads per process. There are several benefits to this extension, not the least of which is concurrent programming.
However, such improvements in operating system technology have given rise to the problem addressed by the instant invention. With the advent of multithreaded systems, the requirement has arisen that the libraries associated therewith must be modified to either be thread-efficient or at the very least thread-safe. The added complexity of multiprocessor forms of such systems only exacerbates the problem of maintaining system integrity.
Applications which have been bound unshared with libraries do not require changes to the libraries inasmuch as they will maintain the single process model (e.g. a single thread, single process model). However, in other cases wherein the process model changes from a single thread single process to multiple threads per process, methods and systems were required to be devised which could render such libraries effectively thread-efficient or at least thread-safe. The practical constraint of programming resources simply renders it impractical to thread-safe all library routines in a modern multithreaded system. Thus, systems and methods were needed to enable the creation of multithread-safe shared libraries without the necessity for source code modifications of the library itself.
By way of further background, a typical multiprocessor environment with shared resource management may be seen described in U.S. Pat. No. 5,109,511 entitled "Shared Resource Managing Method and System". However, in this system no lock operations are provided for. In yet another reference, U.S. Pat. No. 4,847,754, there is disclosed another multiprocessor environment providing for serialization of access to shared resources among concurrent processes which does call for a lock mechanism. However the system provides for a two-step serialization process requiring an access initiation operation followed by an access completion operation.
Yet another shared resource system for concurrent processes in a multi-process environment may be seen in "Memory Protection Software Facility for OS/2 Shared Data Application", IBM Technical Disclosure Bulletin, Vol. 34, No. 4A, 9/91. This reference describes a technique for isolating memory areas in, for example, Intel 386 architected systems wherein a facility is provided for dynamic link libraries (DLLs) to protect their critical shared global data regions. However, no protection is provided for the DLLs from each other, the technique disclosed requires altered process address spaces, and, moreover, has undesirable hardware dependencies.
Several approaches to addressing the specific problem met by the subject invention are available, all of which include concomitant and very undesirable drawbacks.
As but one example, in seeking to effect multithreaded and multiprocessor shared libraries which are thread-safe, one approach is to simply rewrite all libraries to add locks. As a practical matter, a modern complex computing system may involve numerous such libraries. In the case of the aforesaid AIX system, there are in excess of 70 libraries including, for example, a socket library in excess of one megabyte. Obviously, to rewrite all such libraries would entail a resource commitment far in excess of that which is practical to maintain a commercially viable system.
Yet another approach is simply to do nothing with respect to the existing libraries in terms of rewriting code, but rather simply to document libraries which are not thread-safe. This approach obviously has serious drawbacks itself, not the least of which is maintaining the accuracy of such documentation and the impact on system integrity from errors in documentation.
From the foregoing it may be readily understood that lack of a system and method for creating thread-safe shared libraries has created serious problems with respect to modern complex computing environments, and thus a solution was sorely needed in the industry.
It is accordingly an object of the invention to provide systems and methods for creating thread-safe shared libraries; it is yet a further object of the invention to provide for such shared libraries and their usage without the necessity for source-code modifications of the library.
These and other objects have been fully met by the subject invention, a description of which hereinafter follows which may be more easily understood with reference to the following drawings wherein: